Skip to content

format safety doc of Rc/Arc::from_raw/from_raw_in#154081

Open
hxuhack wants to merge 1 commit intorust-lang:mainfrom
safer-rust:main
Open

format safety doc of Rc/Arc::from_raw/from_raw_in#154081
hxuhack wants to merge 1 commit intorust-lang:mainfrom
safer-rust:main

Conversation

@hxuhack
Copy link
Contributor

@hxuhack hxuhack commented Mar 19, 2026

The following APIs previously had safety notes, but they were not placed under a dedicated Safety section. This PR adds a Safety section for each API and moves the original safety descriptions there:

Additionally, we updated the parameter requirements to clarify that the raw pointer may be returned not only from into_raw, but also from into_raw_with_allocator.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 19, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 19, 2026

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: libs
  • libs expanded to 7 candidates

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

///
/// * Creating a `Rc<T>` from a pointer other than one returned from
/// [`Rc<U>::into_raw`][into_raw] or [`Rc<U>::into_raw_with_allocator`][into_raw_with_allocator]
/// is undefined behavior.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing it is also undefined behavior if the pointer came from a call to into_raw_with_allocator where the returned allocator was not the global one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but there is another safety requirement in the safety section preventing this: the raw pointer must point to a block of memory allocated by the global allocator.

///
/// The raw pointer must have been previously returned by a call to
/// [`Rc<U>::into_raw`][into_raw] with the following requirements:
/// [`Rc<U>::into_raw`][into_raw] or [`Rc<U>::into_raw_with_allocator`][into_raw_with_allocator].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This information is now duplicated in the safety section, but there it is phrased negatively instead. Should perhaps this positive version be moved into the safety section instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I referred to the format used in Thread::from_raw, which follows the same pattern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants